Symposium on Software Performance (SSP) 2015

Einen integralen Bestandteil der Kostenanalyse in Projekten bildet die Schätzung der Aufwände. Hierfür kommen – unabhängig vom gewählten Projektvorgehensmodell – etablierte Methoden zum Einsatz, z.B. Function Point Analyse oder die Expertenschätzung 1 . Üblicherweise wird das Projektcontrolling gegen diese Aufwände erfolgen [ELT14-1]. Bezogen auf agile Projekte stellt sich die Frage, welchen Mehrwert eine Schätzung der User Stories in Story Points gegenüber einer Schätzung in echten Aufwänden bietet. Werden Story Points verwendet, stehen Projekte dann häufig vor der Herausforderung, diese Schätzungen sinnvoll methodisch zu integrieren. Beiden Fragen werden wir im Folgenden auf den Grund gehen. Mehrwert von Story-Point-Schätzungen. Als einer der Vorteile agiler Methoden gegenüber klassischen Vorgehensweisen wird häufig angeführt, dass durch das Pull-Prinzip bei der Aufgabenverteilung eine deutlich gleichmäßigere und dem Team angepasste Arbeitsbelastung erreicht wird. [ARW10] Dieser positive Aspekt wird durch die Verwendung von Story Points noch verstärkt. Dies begründet sich durch den augenscheinlichen Unterschied zwischen Story Points (SP) und Personentagen (PT): Während mit PT der technische Umsetzungsaufwand bewertet wird, wird durch SP die Komplexität inklusive der Aspekte Aufwand, Unsicherheit, Risiko und Schwierigkeit einer Anforderung transparent gemacht. Im Folgenden werden all diese Aspekte unter dem Begriff Komplexität zusammengefasst. Genau in dieser Bewertung liegt der immanente Vorteil von SP: Sie sind durch die Verwendung einer vereinfachten Fibonacci-Reihe von Natur aus unscharf, denn durch den Vergleich der Komplexität von Anforderungen untereinander ergibt sich der Schätzwert. Dies hat zur Folge, dass bei der Überlegung, wie viele Aufgaben das Team im nächsten Sprint schaffen wird, ausschließlich die Anzahl der SP, die es sich in diesem Sprint zutraut, eine Rolle spielt. Die velocity hilft dem Team dabei seine Entscheidung zu plausibilisieren. Schätzt man dagegen die Anforderungen direkt in PT ab, wird man und auch 1 Der umgekehrte Weg ist auch möglich: Basierend auf einem zur Verfügung stehenden Budget werden die Aufwände auf die geforderten Produktmerkmale verteilt, wobei ein größtmöglicher Nutzen erzielt werden soll. (Buy-AFeature) das Team immer versucht sein, die verfügbaren Ressourcen vollständig auszulasten, um möglichst viel Wert pro Zeit zu schaffen. [Rein12] Die Kenntnis der Komplexität einer Anforderung hat gegenüber der bloßen Kenntnis des erwarteten Aufwands weitere Vorteile. Zum einen wird die individuelle Leistungsfähigkeit einzelner Teammitglieder in den Hintergrund gestellt. Dies wirkt sich positiv auf die Zusammenarbeit im Team aus, denn Diskussionen über die Arbeitsgeschwindigkeit und Leistungsfähigkeit einzelner Teammitglieder werden vermieden 2 . Zum anderen wird durch die Komplexität auch das mit einer Anforderung verbundene Risiko transparent gemacht: Eine hohe Komplexität geht mit einem hohen Risiko und einer hohen Unsicherheit in der Umsetzung einher. Gleichzeitig zeigen stark abweichende Schätzungen, dass im Team ein Ungleichgewicht im Verständnis der Anforderung herrscht. [ELT14-2] Schätzungen in SP unterstützen also das PullPrinzip und helfen dem Team dabei, seine Auslastung selbst zu steuern. Damit dies verlässlich funktioniert, ist es eine sehr wichtige Aufgabe des Product Owners, die umzusetzenden Stories und Aufgaben in eine Reihenfolge zu bringen, um so auch dem CherryPicking vorzubeugen. Die Reihenfolge wird dabei im Wesentlichen beeinflusst von der Priorität, den Abhängigkeiten, möglichen Quick Wins und Synergieeffekten. Die geschätzten Story Points je Anforderung sind neben dem Business Value und der Abhängigkeit der Backlog Einträge untereinander eines der Kriterien, anhand derer der Product Owner die Anforderungen in eine Umsetzungsreihenfolge bringen kann. Hohe SP Schätzungen sind immer ein Signal dafür, dass diese Anforderung entweder inhaltlich noch nicht vollständig verstanden, zu risikobehaftet oder zu umfangreich ist. In allen drei Fällen ist es ratsam, solche Einträge zunächst noch genauer zu untersuchen, bevor sie ins Sprint Backlog